Zum Hauptinhalt springen

Wie verbinden wir Produktentwicklung und Testberichte?

CertHub ist ein Engineering-Tool. Wenn Informationen an eine Behoerde eingereicht oder von einer benannten Stelle geprueft werden, sollte CertHub die Datenautoritaet sein — der einzige kontrollierte Ort, an dem diese Informationen gepflegt werden.

Das heisst nicht, dass jede Datei, die dein Engineering-Prozess erzeugt, in CertHub liegen muss. Es bedeutet, dass die einreichungsrelevanten Informationen dort gepflegt werden, und alles andere dort bleibt, wo es entstanden ist — mit einem kontrollierten Link zurueck.

Die praktische Aufteilung ist:

  • Behoerdenrelevante Daten leben in CertHub. Anforderungen, Design Inputs und Outputs, Zweckbestimmung, Risiken, Massnahmen und die kontrollierte Verifikations- und Validierungsgeschichte werden in der Produktdatenbank gepflegt und dort getract.
  • Entwicklungsoutputs bleiben am Ort der Erstellung. Laborberichte, CI-Dashboards, JUnit-Baeume, generierte HTML-Reports und vollstaendige Testartefakte bleiben in deinem Testtool, CI-System oder Artefakt-Store. In CertHub hinterlegst du einen kurzen Nachweis-Record mit einem Link zu diesen Artefakten. Siehe Write Evidence Records fuer das API-Muster.

Die Entscheidung, die die meisten Teams treffen muessen​

Grundsaetzlich gibt es zwei Wege, CertHub mit der restlichen IT-Landschaft zu verbinden. In vielen Faellen nutzt ein Unternehmen spaeter beide.

1. Die API nutzen​

Waehle das, wenn dein Team Daten selbst in CertHub uebertragen will.

Das ist in der Regel richtig, wenn:

  • du Anforderungen und Testnachweise jetzt nach CertHub bringen willst
  • deine IT oder dein Integrationspartner eine ueberschaubare Anbindung bauen kann
  • du Zeitplan und Rollout selbst steuern willst
  • du keinen tiefen taeglichen Zwei-Wege-Workflow in einem bestimmten Entwicklungstool brauchst

2. Einen nativen Connector nutzen​

Waehle das, wenn du eine tiefere bidirektionale Verbindung mit einem konkreten Tool brauchst, das deine Teams taeglich nutzen, zum Beispiel Jira, GitHub oder Confluence.

Das ist ein gemeinsames Projekt zwischen CertHub-Ingenieuren und deinem Team. Es geht nicht nur darum, "Daten rueberzuschieben", sondern gemeinsam festzulegen, welche Informationen synchron bleiben sollen und wie.

Es gibt kein zusaetzliches Dritttool zwischen CertHub und deinem System. Gerade bei sensiblen Qualitaets- und Regulatorikdaten ist das wichtig.

Native Connectors sind nicht Self-Service

Native Connectors werden gemeinsam mit dem CertHub-Team eingerichtet. Um zu besprechen, ob ein Connector fuer deinen Anwendungsfall passt, wende dich an deinen CertHub-Ansprechpartner oder schreibe an support@certhub.de.

Auf einen Blick​

AnsatzAm besten geeignet fuerWer baut es
APIEigene Automatisierung im eigenen TempoDein Team
Nativer ConnectorTiefere Zwei-Wege-Synchronisation mit einem konkreten ToolCertHub-Ingenieure gemeinsam mit deinem Team
hinweis

Diese Uebersicht ist nicht vollstaendig. Wenn dein Tool oder dein Szenario hier nicht auftaucht, kann CertHub gemeinsam mit dir pruefen, was sinnvoll ist.

Was muss in CertHub eigentlich ankommen?​

Genau hier brauchen viele Teams Orientierung.

Anforderungen​

Produktanforderungen, Design Inputs, Design Outputs und die zugehoerigen Nachweise sollten in der technischen Dokumentation ankommen — nicht nur in Jira, Polarion, Azure DevOps, GitHub oder einem Wiki.

Warum? Weil QM und RA eine kontrollierte Sicht darauf brauchen, was das Produkt leisten soll, wie diese Anforderung umgesetzt wurde und wie sie verifiziert wurde. CertHub ist der Ort, an dem diese kontrollierte Sicht gepflegt und eingereicht wird.

Testberichte​

Testberichte gehoeren als Verifikations- oder Validierungsnachweis nach CertHub, je nachdem, welche Rolle sie spielen.

CertHub ersetzt nicht dein Testtool oder den Laborablauf. CertHub schafft den kontrollierten, nachvollziehbaren Nachweis fuer die technische Dokumentation:

  • welche Anforderung geprueft wurde
  • welcher Test oder welche Verifikationsaktivitaet sie stuetzt
  • welche Nachweisdatei dazugehoert

Der vollstaendige Bericht selbst — das PDF, das HTML-Dashboard, die Rohdaten — bleibt dort, wo er erstellt wurde. In CertHub pflegst du den kontrollierten Record und einen Link zu diesem Artefakt. So bleibt der Nachweis nachvollziehbar und auditierbar, ohne schwere Dateien zu duplizieren.

Welche Option solltest du waehlen?​

Nutze diese einfache Regel:

  • Wenn Anforderungen und Testnachweise jetzt und nach eurem eigenen Zeitplan nach CertHub kommen sollen, waehle die API.
  • Wenn deine Entwicklungsteams einen tieferen taeglichen Zwei-Wege-Workflow mit einem konkreten Tool brauchen, plane einen nativen Connector mit CertHub.
  • Wenn du nur einmal eine Tabelle uebernehmen willst, nutze den Import und belasse es dabei.

Was du nicht tun solltest​

Das sind die haeufigsten Fehler, die Teams bei der Verbindung von Entwicklung und CertHub machen:

  • Behalte die behoerdenrelevante Quelle der Wahrheit nicht in Word, Confluence oder dem Entwicklungstool. Wenn Informationen an eine Behoerde eingereicht oder im Audit verteidigt werden sollen, pflege sie in CertHub. Eine Kopie in Jira oder Confluence ist keine kontrollierte technische Dokumentation.
  • Kippe keine vollstaendigen Testberichte, CI-Baeume oder Dashboards in CertHub. Diese Outputs gehoeren dorthin, wo sie erstellt wurden. Speichere sie in deinem CI-System, Artefakt-Store oder Labor-Tool und halte in CertHub einen kontrollierten Nachweis-Record mit Link. Siehe Write Evidence Records.
  • Importiere keine Testnachweise, ohne sie mit der Anforderung zu verknuepfen, die sie stuetzen. Unverknuepfte Nachweise schwaehen deine Audit-Story, selbst wenn der Test gut durchgefuehrt wurde.
  • Behandle Beschwerden, CAPAs oder Audits nicht wie Produktentwicklungsdaten. Das sind QMS-Aktivitaeten, die durch SOPs, Templates mit Input Fields und QM Lists gesteuert werden — keine Produktdaten. Siehe Wo gehoert diese Information hin?.
  • Pflege keine zweite, unverbundene Kopie von Risiken oder Anforderungen ausserhalb von CertHub. Wenn CertHub die Datenautoritaet ist, sollte das Entwicklungstool eine synchronisierte Kopie aus CertHub erhalten, nicht umgekehrt.

Ein praktisches Beispiel​

Stell dir vor, deine Design Inputs liegen in Jira und deine Verifikationsberichte entstehen ausserhalb von CertHub als PDFs.

Der empfohlene Aufbau ist:

  • die Entwicklung arbeitet weiter in Jira
  • die relevanten Anforderungen werden nach CertHub uebernommen — CertHub wird die kontrollierte Quelle der Wahrheit fuer diese Anforderungen
  • nach Abschluss der Verifikation wird ein kurzer Nachweis-Record nach CertHub geschrieben, mit einem Link zum vollstaendigen Bericht im Artefakt-Store
  • das PDF bleibt im Artefakt-Store oder Labor-System; CertHub haelt den kontrollierten Verweis

So erhalten QM und RA eine pruefbare Sicht auf die technische Dokumentation, ohne dass das Engineering seine gewohnten Werkzeuge aufgeben muss, und ohne schwere Dateien in ein System zu kopieren, das sie nicht speichern muss.

Zwei Richtungen, nicht nur eine​

Die meisten Teams denken daran, Daten nach CertHub zu bringen, aber die Verbindung funktioniert in beide Richtungen:

  • Hinaus: Exportiere kontrollierte Anforderungen und Verifikationsdefinitionen, damit deine Engineering-Tools sie nutzen koennen.
  • Hinein: Schreibe beim Release einen kurzen Nachweis-Record zurueck nach CertHub, der auf den vollstaendigen Nachweis in deinem CI- oder Artefakt-Store verweist.

Der Nachweis-Record muss nicht den gesamten Build-Baum oder jedes Testergebnis enthalten. Eine Versionsnummer, ein Commit, ein Zeitstempel, eine URL zum CI-Lauf und eine kurze Zusammenfassung reichen oft aus. Behalte die grossen Artefakte dort, wo sie hingehoeren, und gib CertHub den kontrollierten Verweis.

Wenn dein Produkt Software enthaelt, lies Wo lebt das V-Modell bei Softwareentwicklung? fuer einen tieferen Blick darauf, welche Teile des V-Modells nach CertHub gehoeren und welche ausserhalb bleiben.

Empfehlung​

Wenn deine unmittelbare Frage lautet: "Wie bekommen wir Anforderungen und Testberichte nach CertHub?", dann ist die Antwort meist ueber die API.

Plane einen nativen Connector dann, wenn der fachliche Bedarf groesser ist und ihr einen fortlaufenden Zwei-Wege-Workflow in einem konkreten Tool wollt.

Funktionierendes Beispiel

Cadence ist CertHubs oeffentliches Engineering-Beispiel. Es setzt den API-Ansatz um; useblocks (Sphinx-Needs / CodeLinks / Test-Reports) ist der optionale Last-Hop-Toolchain in diesem Repo. Siehe Working example.

Wenn du das jetzt in CertHub umsetzen willst​